REMARKS 

This is a full and timely response to the non- final Office Action of September 17, 
2002. Reexamination and reconsideration are respectfully requested. 

5 I. C laims L 5 to 7, and 9 to 12 are patentable over Kling et al. 

The Examiner rejected claims 1 5 5 to 7, and 9 to 12 under 35 U.S.C. § 103 as being 
unpatentable over U.S. Patent No. 5,878,215 to Kling et al. With respect to claim 1, the 
Examiner considered Kling to disclose a method which comprises steps of receiving 
transactions, converting the transactions into messages, assigning priorities to the messages, 

10 processing the higher priority messages, and then processing the lower priority messages 
when resources are available. The Examiner stated that the processing described in Kling 
can occur in essentially real-time and can be interspersed with the processing of a second 
type of messages. The Examiner recognized that Kling does not disclose a posting activity 
but argued that it would have been obvious to have included a posting type message since 

15 this would enable the account balance inquiry. The Examiner further stated that if posting 
were not done on a timely basis, the financial balance inquiry would not be possible. 

Kling describes a system and method for processing transaction requests between 
remote terminals and a financial institution. With reference to Figure 1 , the remote terminals 
103, 105, and 107 communicate with financial institutions 109 and 1 1 1 through a switch 101. 

20 Kling describes a data group, which is shown in Figure 2, having urgency indicators 205, 
213, and 223 for indicating whether a service request is "transaction interactive," "batch 
interactive," or "non-interactive" (see column 5, lines 8 to 13). The transaction interactive 
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requires an immediate response to the remote terminal, the batch interactive requires a global 
response only after all messages in the batch have been received by the switch, and the non- 
interactive requires no further response. Figure 5 of Kling provides a block diagram of the 
switch 101 and Figure 6 provides a flow chart of operation for the switch. 
5 As should be apparent from the summary of Kling given above and from Kling itself, 

Kling is primarily directed to the protocol and communications between remote terminals and 
the financial institution. As mentioned above, the block diagram in Figure 5 and the flow 
chart in Figure 6 relate to the switch 101, and not to the operations of either the remote 
terminal or the financial institution. Significantly, Kling does not provide any description or 

10 details on how the financial institutions internally process the service requests. 

Claim 1 had previously recited a "method for posting transactions to accounts" and 
claim 7 had referred to a "method for updating an account." These claims have been revised 
to make explicit that the methods are "performed for a financial institution." Both the 
posting method of claim 1 and the method of updating an account are performed for a 

15 financial institution and so these revisions to the claims simply make explicit that the 

methods are performed for the financial institution. As demonstrated by new claims 1 7 and 
18, the methods may be performed by the financial institution itself or may be performed on 
behalf of the financial institution, such as by a third party processor. Furthermore, the 
financial institution may be a card processing company or may be a commercial entity that 

20 processes their own accounts, such as a Home Depot or Sears. 

As mentioned above, Kling does not provide any details or description on how the 
financial institutions 109 and 1 1 1 internally process service requests initiated by the remote 
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terminals. Kling provides no description or suggestion on any method for posting 
transactions which involves, inter alia converting transactions into messages, assigning a 
lower priority to messages ready for posting relative to a second type of messages, processing 
the second type of messages at the higher priority, and then posting transactions to the 
5 accounts when system resources are available. The rejection of claims 1 to 12 should 
consequently be withdrawn. 

Conventional processing systems, as described in the Background section of the 
application, update accounts and post transactions in batches. These systems suffered from a 
disadvantage in that the systems could not provide up-to-the-date information and otherwise 

10 act in real time. The Examiner argued that the account balance inquiry in Kling inherently 
means that Kling must process in real-time rather than in batch mode. The account balance 
inquiry does not establish anything about how posting occurs for a financial institution nor 
does it explain how accounts are updated . The account balance inquiry may simply provide 
the account balance as determined from the prior night's batch processing of all accounts 

15 without regard to any intermediate transactions received during the day. In any event, the 
manner in responding to an account balance inquiry does not suggest the method of posting 
transactions to accounts or the method of updating accounts. 

As established above, Kling does not describe nor does it suggest any method for 
posting or updating accounts which involves posting transactions to the accounts when 

20 systems resources are available and processing a second type of messages at a higher priority 
than those messages ready for posting. 

With respect to claims 5, 6, 9, and 10 the Examiner argued that Kling discloses plural 

-6- 

ATLLIBOl 1454466.1 



and one at a time transaction receipt. Claim 5 specifies that receiving transactions comprises 
receiving transactions at a plurality of times throughout a day while claim 6 states that a 
group of transactions are received at one time. As specified in claim 1, after the transactions 
are received, they are converted into messages, priorities are assigned, and then the messages 
5 are processed on the priority such that the second type of messages are processed at the 
higher priority than the posting messages, which are processed when system resources are 
available. Kling does not suggest any processing of transactions in either batch nor in 
essentially real-time that allocates priorities to messages and then processes the messages 
based on the priority. The portion of Kling cited by the Examiner relates to whether a 

10 response is required and does not disclose how those service requests are actually processed 
for the financial institution. The rejection of claims 5 and 6 should therefore be withdrawn. 

With respect to claim 7, the Examiner argued that Kling discloses the claimed method 
which includes associating a rule, storing a parameter, receiving a transaction, identifying 
rules, applying the rules, inserting the transaction, and propagating balances. The Examiner 

15 recognized that Kling does not specifically disclose that a rule has changed by parameter 
modification but that it would have been obvious since it would be "more logical for 
particular transaction messages to be processed first because of time constraints/ 5 

As demonstrated above, Kling does not provide any disclosure or teaching on how the 
accounts are processed and updated for the financial institution. Thus, Kling does not 

20 anticipate nor does it render obvious the subject matter of claims 7 to 12. Since Kling does 
not provide any suggestion for the claimed method for updating an account, the rejection of 
claims 7 to 12 must be withdrawn. 
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The rejection of claims 7 to 12 is improper for other reasons as well. For instance, 
claim 7 states that the method for updating an account includes storing at least one parameter 
of the rule in a database . The Examiner referenced column 7, lines 48 to 60, of Kling which 
describes how customer information may be contained within databases. Significantly, in 
5 this section of Kling, Kling does not state that any parameter of a rule can be stored in a 
database. As set forth in claim 7, the rule is "used in controlling a processing of the 
account." Claim 7 also states that the "rule is changed by modifying the parameter stored in 
that database." Kling does not provide any suggestion that the manner in which an account is 
processed can be changed by modifying the parameter in a database. 

10 The Examiner argued that the subject matter of claim 7 would have been obvious to 

account for the urgency of a transaction. The ability to change a rule by modifying the 
database greatly simplifies the coding of how accounts are processed. Rather than adding 
additional code, which entails coding, compiling, and testing, the claimed method allows a 
rule to be updated or otherwise altered by a simple change in the database. Kling provides no 

15 suggestion for any such method for updating accounts. The rejection of claims 7 to 12 must 
therefore be withdrawn. 

With respect to claims 1 1 and 12, the Examiner argued that it would have been 
obvious to have projected accounts to allow "a warning" during which accounts can be 
monitored for usage trends. Claims 1 1 and 12 illustrate the flexibility of the claimed method 

20 for updating accounts in that the projecting of the account can occur either prior to or after 
the inserting of the transaction. Pages 91 and 92 of the application describe a preferred way 
in which projection occurs. As explained in this section of the application, the projection "is 
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a key operation and can be analogized as a spreadsheet with time advancing down the rows." 
A first column contains transaction information and later columns contain various balances. 
Kling provides no suggestion as to how the projecting of an account can occur and the 
Examiner has not provided any motivation as to how it would have been obvious to have 
5 projected "prior to the inserting" as set forth in claim 1 1 or "after the inserting" as set forth in 
claim 12. The Examiner is respectfully requested to withdraw the rejection of claims 1 1 and 
12. 



II. Claims 2 to 4 are patentable over Kling et al. in view of Hogan. 

10 The Examiner rejected claims 2 to 4 under 35 U.S.C. § 103 as being unpatentable 

over Kling et al. in view of U.S. Patent No. 5,692,132 to Hogan. In making this rejection, the 
Examiner stated that Kling does not specifically disclose a transaction message as an 
authorization. The Examiner, despite making such an admission, does not provide any 
reasoning as to why such subject matter would have been obvious in light of Hogan. 

15 Because the Examiner has failed to establish a prima facie case of obviousness, the rejection 
of claims 2 to 4 must be withdrawn. 

Furthermore, the combination of Hogan with Kling would not suggest the claimed 
invention. These references do not suggest a method for posting transactions in which an 
authorization request is processed at a higher priority than the posting of transactions. The 

20 rejection of claims 2 to 4 must therefore be withdrawn. 
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III. Claim 8 is patentable over Kling et al. in view of Auditing 
The Examiner rejected claim 8 under § 103 as being unpatentable over Kling et al. in 
view of page 297 in the book Auditing by Robertson et al. The Examiner stated that it would 
5 have been obvious to have used an account master as disclosed by Auditing since this would 
have allowed for changes to be made for many instances of a particular account with a 
change to a single account master. 

Neither Kling nor Auditing discloses the subject matter of claim 8. Claim 8 relates to 
associating a rule and states that this step comprises "generating an account master and 
10 identifying all rules comprises retrieving the account master." Auditing, in contrast, refers to 
master files which may contain static fields such as employee number and dynamic fields 
such as year-to-date gross-pay. These master files described in Auditing do not correspond to 
the claimed account master which associate rules with an account and, by retrieving the 
account master, the method can identify all rules used in controlling a processing of the 
15 account. Because Kling does not disclose any account master relating to the rules used in 
"controlling a processing of the account," the combination of Auditing with Kling would fail 
to render the claimed invention obvious. The rejection of claim 8 should therefore be 
withdrawn. 
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IV. Conclusion 

For at least the above reasons, claims 1 to 12 are in condition for allowance. New 
claims 13 to 18 are allowable for at least the reasons that claims 1 to 12 are allowable. If the 
Examiner has any comments or suggestions which can place this application in even better 
form, the Examiner is encouraged to telephone the undersigned at the below-listed number. 

Please charge any additional fees or credit any overpayment to Deposit Account 
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OF COUNSEL: 
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Attorney Docket No.: 48535/268245 
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Geoff L. Sutcliffe 
Reg. No. 36,348 
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MARKED UP COPY OF AMENDED CLAIMS PURSUANT TO 37 C.F.R. S 1.121(c). 



1 LA method performed for a financial institution having system resources for 

2 posting transactions to accounts, comprising: 

3 receiving for the financial institution transactions related to a plurality of the accounts; 

4 converting the transactions into messages; 

5 assigning a lower priority to messages ready for posting relative to a second type of 

6 messages; 

7 processing, with the system resources, the second type of messages at the higher 

8 priority than messages ready for posting; and 

9 posting transactions to the accounts when the system resources are available; 

10 wherein the posting of the transactions can occur in essentially real-time and can be 

1 1 interspersed with the processing of the second type of messages. 

1 7. A method performed for a financial institution for updating an account having 

2 account information, comprising: 

3 associating at least one rule with the account, the rule for being used in controlling a 

4 processing of the account; 

5 storing at least one parameter of the rule in a database; 

6 receiving for the financial institution a transaction related to the account; 

7 identifying all rules associated with the account; 

8 applying the rules to the transaction; 
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9 inserting the transaction into the account information; and 

10 propagating balances maintained for the account; 

1 1 wherein the rule is changed by modifying the parameter stored in the database 
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